A database comprises data and metadata that is stored on one or more storage devices, such as a set of hard disks. Such data and metadata may be stored in a database logically, for example, according to relational and/or object-relational database constructs. Database applications interact with a database server by submitting to the database server commands that cause the database server to perform operations on data stored in a database. A database server is a combination of integrated software components and an allocation of computational resources, such as memory, a computing device, and processes on the computing device for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function to process requests to access a database. A database command is a request to access data from a database. The command may be to perform operations on the data in the database or return the data from the database. Database commands may be in the form of a database statement. For the database server to process the database statements, the database statements supplied to the database server are statements that conform to a database language supported by the database server. One non-limiting database language supported by many database servers is SQL, including proprietary forms of SQL supported by such database servers as Oracle, (e.g. Oracle Database 10 g).
Data is typically stored according to redundancy settings for collections of physical disks called disk groups. If the disk group stores data with normal redundancy, for example, then two copies of the data are maintained, or mirrored, among at least two failure groups. A failure group is one or more disks of a disk group that share a common resource. In other words, disk groups are organized into failure groups such that a failure of one resource, such as a disk controller, can only cause a failure of one failure group. A high redundancy disk group maintains multiple mirrored copies of the data in multiple failure groups, such as two, three or more. A no redundancy disk group maintains only a single copy of the data with no mirroring, and that single copy may be maintained in one or more failure groups. Some disk groups without redundancy rely on external systems to maintain redundancy.
Enforcing data redundancy can be expensive. Storing data with normal redundancy consumes twice the overall disk space than storing data with no redundancy. Additional disks, higher capacity disks, and faster disks may need to be purchased and used in order to store the redundant copy or copies. Also, writing multiple copies consumes more bandwidth than writing a single copy. Writing multiple copies may take a considerable amount of extra time if there are not enough disks to support the writing in parallel. For example, in a well-balanced two-disk system, storing 2 GB of data without redundancy may involve storing half of the data on one disk and half of the data on the other disk, consuming a bandwidth of 1 GB for each disk. Storing 2 GB of data with redundancy would consume 2 GB of bandwidth in each of at least two failure groups. If the system is a two-disk system, then each failure group includes a single disk, and twice the amount of bandwidth per disk is consumed than in the system without redundancy. In this case, we would have to write 2 GB on each of two disks, for a total of 4 GB.
Despite the additional cost of data redundancy, database administrators often choose at least normal redundancy for disk groups in order to facilitate data recovery in the case of a disk failure. The mirrored copies are stored on separate failure groups so that one mirrored copy may be retrieved in case the failure group holding the other mirrored copy fails.
A disk group is a collection of disks that stores data for a database. For example, a disk group may store objects such as tables, relational tables, indexes, and object tables in a tablespace. A tablespace is a portion of the database, such as one or more data files, used to store database objects such as tables, columns, and indexes. For example, a tablespace may store two relational tables, an index, and an object table. Database metadata, which define database objects, also define what portions of a tablespace, such as segments and blocks, are used to store database object data.
A tablespace may be permanent or temporary. Permanent tablespaces are stored beyond the time boundaries of a session or transaction, and temporary tablespaces store temporary tables and temporary indexes that generally exist only for the duration of a user's session. For example, a temporary tablespace may be assigned to a user when the user establishes a database session. A temporary tablespace may be shared by multiple users or may be used by only a single user.
A tablespace may be created in a disk group with no redundancy, normal redundancy, or high redundancy. Data is maintained in the tablespace according to the redundancy level for the disk group. For example, two copies of the data are written to disk for every write operation performed to a tablespace in a normal redundancy disk group. Checksums and other error-checking techniques are used to detect errors in each of the mirrored copies. As long as there are no errors, read operations are performed by reading from only one of the mirrored copies.
When performing operations on large sets of data, such as in data warehousing, results of the operations are stored in a temporary tablespace on disk when the results do not fit in the available volatile memory. For example, if the temporary tablespace is stored with normal redundancy, then two copies of a result of the operation would be stored on disk. If the disk group containing the temporary tablespace fails, then the redundant copy is used to recover the result. If there is no redundant copy of the temporary tablespace, then the data stored in the temporary tablespace may be lost due to the disk failure.
Currently, redundant disk groups storing temporary tablespaces consume a large amount of resources to store redundant data on disk, a large amount of bandwidth for redundant write operations, and potentially a large amount of data I/O time for redundant write operations. On the other hand, disk groups storing temporary tablespaces without redundancy provide no protection against disk failure.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.